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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in 
the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television 
services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters 
market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the 
broadcast industry. 
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Scope 



The present document includes the definition of the Generic Stream Encapsulation (GSE) protocol, which allows for 
efficient encapsulation of IP and other network layer packets over a "generic" physical layer. Such a "generic" physical 
layer is intended as a transport mode that carries a sequence of data bits or data packets, possibly organized in frames, 
but with no specific timing constraints. 

The first generation of DVB standards only supported data transport using the MPEG format (see ISO/IEC 
13818-1 [2]), with a Transport Stream packet multiplex (MPEG-TS). Multi Protocol Encapsulation (EN 301 192 [3]) is 
the DVB standard for encapsulation of audio/video and other content on MPEG-TS packets. The second generation of 
DVB standards features backwards compatibility modes for carrying MPEG-TS as well as generic modes for carrying 
arbitrary packets of variable length. These are referred to as Generic Streams (GS). 

The GSE protocol has been devised as an adaptation layer to provide network layer packet encapsulation and 
fragmentation functions over Generic Stream. GSE provides efficient encapsulation of IP datagrams over variable 
length Layer 2 packets, which are then directly scheduled on the physical layer into Base Band frames. 

GSE maximizes efficiency of IP datagrams transport reducing overhead by a factor 2 to 3 with respect to MPE over 
MPEG-TS. This is achieved without any compromise of the functionalities provided by the protocol, due to the variable 
length Layer 2 packet size, suited to IP traffic characteristics. For example in an interactive DVB-S2 system, the 
overhead is reduced on average from about 10 % for MPE/MPEG-TS to 2 % to 3 % for GSE. Hence yielding an overall 
throughput gain of about 5 % to 15 %, the actual benefit is of course dependent on the concrete system and traffic 
characteristics. 

In addition to the overhead reduction, GSE provides a more efficient system operation for interactive systems that 
utilize advanced physical layer techniques such as for instance Adaptive Coding and Modulation (ACM). The inherent 
channel rate variability experienced in ACM systems makes the Generic Stream format more suited than the Transport 
Stream. GSE provides a flexible fragmentation and encapsulation method, which permits use of a smart scheduler to 
optimize system performance, either by increasing the total throughput and/or by improving the average packet end-to- 
end delay. In addition, GSE flexibility leads to a reduction in packet loss under fading variations, allowing the scheduler 
at the transmitter to dynamically change transmission parameters (for example modulation format, coding rate) for a 
particular network layer packet. 

GSE also provides additional features that increase the protocol flexibility and applicability. Some key GSE 
functions/characteristics are: 

1) Support for multi-protocol encapsulation (IPv4, IPv6, MPEG, ATM, Ethernet, 802. IpQ VLANs, etc.). 

2) Transparency to network layer functions, including IP encryption and IP header compression. 

3) Support of several addressing modes: In addition to the 6-byte MAC address (including multicast and unicast), 
it supports a MAC addressless mode, and an optional 3-byte address mode. 

4) A mechanism for fragmenting IP datagrams or other network layer packets over Base Band frames to support 
ACMA^CM. 

5) Support for hardware filtering. 

6) Extensibility: additional link protocols can be included through specific protocol type values (e.g. Layer 2 
security, IP Header Compression, etc.). 

7) Low complexity. 
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References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI EN 302 307: "Digital Video Broadcasting (DVB); Second generation framing structure, 

channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering 
and other broadband satellite applications". 

[2] ISO/IEC 13818 (parts 1 and 2): "Information technology - Generic coding of moving pictures and 

associated audio information" . 

[3] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". 

[4] IETF RFC 4326: "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP 

Datagrams over an MPEG-2 Transport Stream (TS)". 

[5] IETF RFC 3819: "Advice for Internet Subnetwork Designers". 

[6] IETF RFC 3309: "Stream Control Transmission Protocol (SCTP) Checksum Change". 

[7] IETF RFC 1 112: "Host extensions for IP multicasting". 

[8] IETF RFC 2464: "Transmission of IPv6 Packets over Ethernet Networks". 

[9] draft-ietf-ipdvb-ule-ext-04.txt: "Extension Formats for Unidirectional Lightweight Encapsulation 

(ULE) and the Generic Stream Encapsulation (GSE)". 

2.2 Informative references 

[10] ETSI TR 101 162: "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) 

codes for DVB systems". 
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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACM Adaptive Coding and Modulation 

ATM Asynchronous Transfer Mode 

BB Base Band 

CRC Cyclic Redundancy Check 

DVB Digital Video Broadcast 

E End indicator 

EBU European Broadcasting Union 

FragID Fragmentation Identifier 

GS Generic Stream 

GSE Generic Stream Encapsulation 

lANA Internet Assigned Numbers Authority 

IEEE Institute of Electrical and Electronics Engineers 

IETF Internet Engineering Task Force 

IP Internet Protocol 

IPR Intellectual Property Rights 

ISO International Standard Organization 

JTC Joint Technical Committee 

LT Label Type indicator 

MAC Medium Access Control 

MODCOD MODulation and CODing 

MPE Multi Protocol Encapsulation 

MPEG Moving Pictures Experts Group 

MPLS Multiple Protocol Label Switching 

NPA Network Point of Attachment 

PDU Protocol Data Unit 

QoS Quality of Service 

RCS Return Channel System 

RFC Request For Comment (IETF standard) 

S Start indicator 

SI Service Information 

TS Transport Stream 

ULE Unidirectional Lightweight Encapsulation 

VCI Virtual Channel Identifier 

VLAN Virtual LAN 

VPI Virtual Path Identifier 

VCM Variable Coding and Modulation 



Generic Stream Encapsulation (GSE) Protocol 



4.1 GSE Principles 



Figure 1 illustrates GSE operation. IP datagrams, Ethernet Frames, or other network layer packets, herein named 
Protocol Data Units (PDUs), that are scheduled for transmission, are encapsulated in one or more GSE Packets. The 
encapsulation process delineates the start and end of each network-layer PDU, adds control information such as the 
network protocol type and address label, and provides an overall integrity check when needed. 

The PDU may be encapsulated in a single GSE Packet or sliced into PDU fragments and encapsulated in several GSE 
Packets. GSE Packets have in general variable length, in order to match the input IP traffic with minimum overhead. 

GSE Packets may be sent in different Base Band frames, not necessarily consecutive or with the same transmission 
parameters (modulation format, coding rate). Moreover, no constraint on the GSE Packet position within the frame is 
assumed. However, GSE Packets shall not be reordered between encapsulator and de-encapsulator. In general, a Base 
Band frame may multiplex more than a single GSE Packet. Base Band frames may have fixed or variable length. 
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GSE does not include a mechanism for integrity check of single GSE Packets. A CRC-32 is only appended to the last 
PDU fragment of a fragmented PDU to verify the correctness of the reassembly operation. GSE relies on the physical 
layer being able to ensure the required error detection and/or correction probability (see [5] for best current practices in 
IP networks). The present approach is independent of the specific physical layer provided that this meets the required 
level for error detection capability. 
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Figure 1: GSE encapsulation within DVB protocol stack 



In a system where ACM is utilized, transmission parameters typically change dynamically on a frame-by-frame basis. A 
receiver will generally successfully decode only a subset of the transmitted frames, i.e. only the ones whose 
transmission parameters are compatible with the receiver's current channel conditions. GSE does not require that Base 
Band frames include a payload unit start indicator signalling the position of the first GSE packet in the frame. GSE 
requires that a Base Band frame always starts with the GSE Header of the first GSE Packet. GSE Packet fragmentation 
between Base Band Frames is therefore not allowed. 

GSE Packets, including fragments of the same encapsulated PDU, can be scheduled without any restriction (on the 
frame transmission parameter, on the frame position within the sequence of frames or on the GSE Packet position 
within the frame) in the Base Band frames. Transmission of fragments shall be in-sequence, preserving the transmit 
order. The GSE reassembly mechanisms support reconstructing the original PDU regardless of the position of GSE 
Packets in the transmitted frames. 

Optimal efficiency of GSE over a physical layer with ACM requires the encapsulator/scheduler to have a-priori 
knowledge of the Base Band frame lengths (either fixed or variable). Then utilization of the DataField of a Base Band 
Frame can be optimized through PDU fragmentation. GSE can fragment PDUs into fragments of arbitrary size. 
Additional information on processing at the encapsulator and on the interface with the modulator is included in 
annex B. 

4.1.1 PDU Fragmentation and Reassembly 

The basic GSE Header comprises protocol fields to perform fragmentation and encapsulation. The 
fragmentation/reassembly process utilizes a Fragmentation Identifier (Frag ID) label. The Frag ID field is present in the 
GSE Header of each GSE Packet that carries a PDU fragment, and indicates the PDU to which a fragment belongs. This 
mechanism supports reassembly of GSE Packets that are interleaved but carry fragments of different PDUs either 
addressed to the same or different receivers. An integrity check trailer with a CRC32 is appended to the final (end) 
fragment to detect reassembly errors. 
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The maximum number of PDU fragments that can be simultaneously present on each GS stream is N=256. When the 
forward channel is considered, a single point-to-multipoint data stream shared between receiver terminals shall be 
assumed. On the other hand, in the case of the return channel, where multipoint-to -point connectivity is in place, a 
number of point-to-point data streams between each transmitter and the receiver terminal shall be assumed. When the 
sender has completed transmission of a given PDU, the associated Frag ID value is freed and can be used to fragment 
another PDU. The number of 256 Frag IDs is considered to exceed the needs of current systems and is foreseen to be 
adequate for next generation systems as well. Therefore, receivers may limit the number of buffers used to less than 
256, depending on the system and on the application (see annex A). 

The header of each GSE Packet carries a one bit Start Indicator (S bit) in the most- significant bit. An S bit with a value 
of " 1 " indicates the start of a PDU after the GSE Header. Additionally the GSE Header has an End Indicator (E bit) as 
the second-most-significant bit in the header. An E bit with a value of "1" indicates the end of a PDU within the GSE 
Packet data field. In case both S and E bit have the value " 1 " the GSE Packet shall carry a complete PDU. The 
maximum GSE Packet length is 4KB, this length is carried in the right-most 12 bits of the first two bytes in the GSE 
Header. A PDU that cannot be carried in a single GSE Packet needs to be fragmented. 

4.1 .2 Network Protocol Identification 

The GSE Header includes a 2 byte Protocol Type/Extension field that indicates the type of protocol carried by the PDU. 
The Protocol Type field is given in the GSE Header for each complete PDU or the first fragment of an encapsulated 
PDU and uses the method defined in the Unidirectional Lightweight Encapsulation (ULE) protocol [4] . Extension 
headers may therefore be defined as in ULE. This approach allows efficient support for a number of PDU formats, 
including IPv4, IPv6, Ethernet, MPLS, arp, 802. IpQ, etc., and permits inclusion of new protocol types. Moreover, it 
provides a format for Layer 2 security mechanisms, providing functions such as encryption, identity hiding, and 
authentication methods, without modification of the GSE Header structure. 

4.1 .3 Addressing and Hardware Filtering 

GSE supports four addressing formats. The default method uses a 6-byte Label (e.g. a IEEE MAC address). It also 
introduces a 3 -byte Label to save overhead in specific cases (see clause 5) and a format with no Label in the GSE 
Header, either for broadcasting services or for networks, where IP address (or other network layer addressing) 
processing is implemented. In order to reduce MAC signalling within one single Base Band frame a fourth option 
(called label re-use) allows to reuse the Label of the previous GSE Packet for subsequent GSE Packets in a given Base 
Band frame to the same destination address. 

To indicate the used format, the GSE Header contains a Label Type Indicator (LT) field of length 2 bits. The value of 
the Label Type Indicator indicates whether the Label has a length of 6 bytes, or of 3 bytes, or no label is present or label 
re-use is active. When a Label is present, the receiver shall check the Label and discard any GSE Packet, whose label 
does not match one configured at the receiver. The GSE Length field in the GSE Header permits the receiver to discard 
the remainder of a Packet that is not forwarded, by pointing to the start of the following GSE Packet. When the LT 
value indicates broadcast operation (or IP header processing), all receivers shall process the GSE Packet. Finally, in the 
case of Label re-use, a receiver shall process a GSE Packet, if and only if the address of the last previously provided 
GSE Packet matched a receiver address. Label re-use is restricted within the same Base Band frame. 



4.1 .4 Locating GSE Streams 



The receiver terminal shall determine when GSE protocol is applied to a certain received information stream. In the 
specific case of DVB-S2 for instance, this information is carried in the SYNC field of the Base Band frame header 
(see [1]). 

Depending on the physical layer standard, multiple streams may be multiplexed at the transmitter and simultaneously 
received at the terminal side. Each stream shall be considered as a separate logical channel. Therefore, GS 
encapsulation, including fragmentation, shall be carried out separately for the incoming data of each generic stream. 
The scope of the Frag ID label is per Generic Stream. 



4.1 .5 Transporting Signalling Information 



The stream used for the signalling information may be a Transport Stream (see clause 6). As an alternative, a single 
Generic Stream may also be used, for which signalling will be defined in the future. 



ETSI 



10 



ETSI TS 102 606 VI .1.1 (2007-10) 



4.2 



GSE Packet Format 



4.2.1 Specification 

A Generic Stream consists of a sequence of possibly variable length Base Band frames. GSE Packets are multiplexed 
and allocated in Base Band Frames as defined in table 1. Encapsulated PDUs, or fragments of a PDU (see clause 4.3), 
are transported in GSE Packets. Padding (when needed) is added after the last GSE Packet in a Base Band frame. When 
information on the actual data occupation of the Base Band frame (for example in DVB-S2 through the Data Field 
Length) is not provided as signalling information in the Base Band Header, the Receiver shall recognize the presence of 
padding through detection of a specific combination of the Start Indicator, End Indicator and Label Type indicator bits 
(see table 2). The Receiver shall discard any GSE packet subsequent to detection of this combination, which shall never 
be used for any GSE Header. 

Table 1 : Syntax for Base Band Frame structure 



Syntax 


Number of bits 


Mnemonic 


Frame ( ) { 






for(j=0;j<Nl;j++) { 






GSE Packet 






} 







Each GSE Packet is composed of a GSE Header followed by a GSE Payload, where the (fragment of the) encapsulated 
PDU is located. The GSE Header is composed of the fields shown in figure 2. The unshaded fields are always present, 
while the shaded fields may be omitted depending on the preceding control fields in the first 4 bits of the GSE Header. 
The presence of possible Extension Headers is determined by the Protocol Type value. The minimum GSE Header 
length is therefore 2 bytes. 



s 


E 


LT 


GSE 
Length 


Frag ID 


Total length 


Protocol Type 


Label 


Ext. headers i^ 



ii>iti 2b 12b 



1B 



3^6 B 



>=2B 



Figure 2: GSE Header format 

The syntax and semantics of the GSE Packet are defined in table 2. 

Table 2: Syntax for GSE Packet structure 



Syntax 


Number of bits 


IVInemonic 


GSE_Packet() { 






Start_Indicator 


1 


bslbf 


End Indicator 


1 


bslbf 


Label_Type_Indicator 


2 


bslbf 


if (Start lndicator=="0" ) and (End Indicator==" 0" ) and 
(Label type indicator==" 00" ) { 






Padding bits 


4 


bslbf 


for(i=0;i<Nl;i++) { 






Padding bytes 


8 


bslbf 


} 






} else { 






GSE_Length 


12 


Uimsbf 


If (Start_lndicator=="0") or (End_Indicator==" 0" ) { 






Frag ID 


8 


Uimsbf 


} 






If (Start_Indicator=="l") and (End_Indicator==" 0" ) { 






Total Length 


16 


Uimsbf 


} 






If (Start_Indicator=="l") { 






Protocol Type 


16 


Uimsbf 


if (Label_Type_Indicator=="00") { 
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Syntax 


Number of bits 


Mnemonic 


6_byte_Label 


48 


Bslbf 


} else if (Label_Type_Indicator=="01") { 






3 byte Label 


24 


Bslbf 


} 






if (Protocol_Type < 1536) { 






for(i=0;i<N2;i++) { 






Extension Header byte 


8 


Bslbf 


} 






} 






} 






for(i=0;i<N3;i++) { 






PDU data byte 


8 


Bslbf 


} 






If (Start_lndicator=="0") and ( "End_Indicator=="l" ) { 






CRC 32 


32 


Rpchof 


} 






} 






} 







The semantics of GSE Packet are as follows: 

Startjndicator: A value of " 1 " indicates that this GSE Packet contains the start of the encapsulated PDU. A value of 
"0" indicates that the start of the PDU is not present in this GSE Packet. For padding, the Startjndicator shall be set to 
"0". 

Endjndicator: A value of "1" indicates that this GSE Packet contains the end of the encapsulated PDU. A value of 
"0" indicates that the end of the PDU is not present in this GSE Packet. For padding, the Endjndicator shall be set to 
"0". 

Label_TypeJndicator: This is a 2-bit field. For padding, the Label_TypeJndicator shall be set to "00". Otherwise, if 
the Startjndicator is set to "0", the Label_TypeJndicator is reserved and shall be set to "11". The values of the 
Label_TypeJndicator have the semantics included in table 3. Definition of labels and addressing modes is included in 
clause 5. 

Table 3: Label Type Indicator semantics 



Value 


Meaning 


"00" 


Indicates that a 6 byte Label is present and shall be used 
for filtering. 


"01" 


Indicates that a 3 byte Label is present and shall be used 
for filtering. 


"10" 


Broadcast. No label field is present. All receivers shall 
process this GSE Packet. This combination shall be used 
also in non broadcast systems when no filtering is applied 
at Layer 2, but IP header processing is utilized [4]. 


"11" 


Label re-use. No label field is present. All receivers shall 
reuse the label that was present in the previous GSE 
Packet of the same Base Band frame. This method is used 
for transmitting a sequence of GSE Packets with the same 
label without repeating the label field. This value shall not 
be used for the first GSE Packet in the frame. 



Padding_bits: Shall be set to "0". 

NOTE 1 : Nl is the number of bytes until the end of the Base Band frame. 

Padding_bytes: Should be set to "0". When used for padding, the Startjndicator, Endjndicator, and 
Label_TypeJndicator shall be all set to "0"/"00". 

GSE_Length: This 12-bit field indicates the length, in bytes, of the GSE Packet counted from the byte following this 
GSE Length field. The GSE Length field allows for a length of up to 4 096 bytes for a GSE Packet. The GSE Length 
field points to the start of the following GSE Packet, or to the end of the Data Field or start of the padding field if the 
GSE packet is the last in the frame. 
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Frag_ID: This is present when a PDU fragment is included in the GSE Packet, while it is not present if Startjndicator 
and Endjndicator are both set to " 1 " . All GSE Packets containing PDU fragments belonging to the same PDU shall 
contain the same Frag ID. The selected Frag ID shall not be re-used on the link until the last fragment of the PDU has 
been transmitted, (see clause 4.3). 

Total_Length: This field is present in the GSE Header carrying the first fragment of a fragmented PDU. The 16-bit 
field carries the value of the total length, defined as the length, in bytes, of the Protocol Type, Label (6 byte Label or 
3 byte Label), Extension Headers, and the full PDU. The receiver shall perform a total length check after reassembly. It 
may also use the total length information for pre-allocation of buffer space. Although the length of a single GSE Packet 
is limited to almost 4 096 bytes, larger PDUs are supported through fragmentation, up to a total length of 65 536 bytes. 

Protocol_Type: This 16-bit field indicates the type of payload carried in the PDU, or the presence of a Next-Header. 
The set of values that may be assigned to this field is divided into two ranges, similar to the allocation of Ethernet and 
shall follow the rules described in [4]. The two ranges are: 

Type 1: Next-Header Type field 

The first range of the Type space corresponds to the range of values to 1535 decimal. These values may be 
used to identify link-specific protocols and/or to indicate the presence of Extension Headers that carry 
additional optional protocol fields (e.g. a bridging encapsulation). The range is sub-divided into values less 
than 256 and greater than 256, depending on the type of extension. The use of these values is co-ordinated by 
an lANA registry [4]. 

Type 2: EtherType compatible Type Fields 

The second range of the Type space corresponds to the values between 0x600 (1536 decimal) and OxFFFF. 
This set of type assignments follow DIX/IEEE assignments (but exclude use of this field as a frame length 
indicator). All assignments in this space shall use the values defined for EtherType, the following two Type 
values are used as examples (taken from the IEEE EtherTypes registry): 

EXAMPLE: 

0x0800: IPv4 Payload 

Ox86DD: IPv6 Payload 

6_byte_Label: This 48-bit field contains the 6-byte label used for addressing (see clause 5). 

3_byte_Label: This 24-bit field contains the 3 -byte label used for addressing (see clause 5). 

NOTE 2: N2 is the length in bytes of the extension headers as defined in [4]. 

Extension_Header_byte: These optional bytes may be used to carry one or more extension header(s). The extension 
header format is defined by the ULE specification [4] . 

NOTE 3: N3 is the length of the encapsulated PDU or PDU fragment in bytes. 

PDU_data_byte: These bytes contain the PDU data. 

CRC_32: This field is only present in a GSE Packet that carries the last PDU fragment. This field shall be set as 
defined in clause 4.2.3. 

4.2.2 CRC-32 Trailer 

When a receiver reassembles a fragmented PDU with fragments scattered over multiple frames, there is a non- 
negligible probability that a fragment may be missing. The error detection capability of GSE shall therefore be 
sufficiently strong to detect a wrong reassembly with a high probability. This is achieved in GSE through the 
computation of a CRC-32 at PDU level for every fragmented PDU. 

Each GSE Packet where the S-bit value is "0" and E-bit value is "1" shall carry a 32-bit CRC field in the last four bytes 
of the GSE Packet. This position eases CRC computation by hardware. The CRC-32 polynomial below shall be used. 
This is a 32 bit value calculated according to the generator polynomial represented 0xl04Cl 1DB7 in hexadecimal: 

x^32 + x^26 + x^23 + x^22 + x^l6 + x^l2 + x^l 1 + x^lO + x^8 + x^7 + x^5 + xM + x^2 + x^l + x^O. 



ETSI 



13 



ETSI TS 102 606 VI .1.1 (2007-10) 



The Encapsulator initializes the CRC-32 accumulator register to the value OxFFFF FFFF. It then accumulates a transmit 
value for the CRC32 that includes all bytes of the PDU payload, of the Total Length, of the Protocol Type, of the Label 
(when present) and possible Extension headers fields, and places this in the CRC Field. In GSE, the bytes are processed 
in order of increasing position. This use resembles, but is different to that in SCTP [6]. 

In the reassembly state the Receiver performs an integrity check by independently calculating the same CRC value of 
all reassembled PDU with the addition of the above mentioned fields, and comparing this with the transmitted value in 
the last GSE Packet trailer. PDUs that do not have a valid CRC, are discarded, causing the Receiver to enter the Idle 
State. 

In figure 3 an example study case is shown, where a PDU is divided in three fragments, which are transmitted in three 
GSE Packets. The shaded fields in figure 3 are the ones that contribute to the CRC calculation: the bytes over which the 
CRC is to be calculated shall be starting from the Total Length field, omitting all subsequent GSE Packet Headers of the 
same Frag ID up to, but not including the CRC field. 
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Figure 3: CRC calculation example 

This description may be suited for hardware implementation, but the present document does not imply any specific 
implementation. Software-based table-lookup or hardware-assisted software-based implementations are also possible. 

The sole purpose of this CRC is to protect a fragmented PDU (header, and payload) from undetected reassembly errors 
and/or errors that may be introduced by unexpected software/hardware operation while the encapsulated PDU 
fragments are in transit across the underlying subnetwork and during processing at the Encapsulator and/or the 
Receiver. It may also detect the presence of uncorrected errors from the physical link (however, as previously 
mentioned, it is assumed that sufficient physical layer error detection capabilities are present). 



4.3 PDU Fragmentation 



GSE Packets with data from the same PDU shall have the same Frag ID and shall be transmitted in order. However, 
they may not be transmitted consecutively, but may be interleaved with GSE Packets carrying full PDUs or fragments 
with a different Frag ID. Reassembled PDUs will be delivered to higher layers in the order of the reception of the last 
fragment of the PDUs. 

The following rules shall apply: 

1) All GSE Packets carrying data of the same PDU shall have the same Frag ID. 

2) The first GSE Packet with a given Frag ID shall have S equal "1" and E bit equal "0". 

3) The GSE Packets carrying PDU fragments, which are neither the first nor the last PDU fragment, shall have S 
equal "0" and E bit equal "0". 

4) The last GSE Packet with a given Frag ID shall have S equal "0" and E bit equal "1". 

5) Whilst a PDU is still incomplete, its Frag ID shall not be reused within a period of 256 BB frames. 
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6) All GSE Packets with the same Frag ID shall be transmitted in order. 

7) The Label shall only be used in the first GSE Packet. 

Whenever fragmentation is to be applied, the GSE Encapsulator takes the first XI bytes of the PDU and: 

• forms a GSE Packet with S bit set to value " 1", E bit set to value "0"; 

• sets the GSE Length Field to the calculated number of bytes including the length of the PDU data XI (see 
figure 3), the length of the Frag ID field, the Total length field, the Protocol Type field, the Label field (if 
present) and any Extension Header. The GSE Payload carries the first part of the encapsulated PDU with 
length XI bytes. The derived GSE length shall not exceed the remaining free space in the current Base Band 
frame Data Field; 

sets Frag ID to a free value; 

sets the Total Length field to the calculated number of bytes including the length of the unfragmented PDU, of 
the Protocol Type field, of the Label field (if present ), and of any extension header; 

adds an appropriate Protocol Type field; 

adds the Label Field, when applicable; 

inserts XI (see figure 3) bytes from the PDU data in the GSE Payload; and 

then places this GSE Packet into the current frame as first GSE packet or after any other GSE Packet already 
present in the frame. 

When the PDU is divided into more than two fragments, the GSE Encapsulator takes the following X2 (see figure 3) 
PDU data and: 

• forms a GSE Packet with S bit value set to "0" and the E bit value set to "0"; 

• sets the GSE Length Field in the GSE Header to the calculated number of bytes including the length of the 
PDU data X2 (see figure 3) and of the Frag ID field. The derived GSE length shall not exceed the remaining 
free space in the current Base Band frame Data Field; 

• sets the Frag ID to the same value as for the previous fragments of this PDU; 

• inserts X2 (see figure 3) bytes from the PDU in the GSE Payload; and 

• then places this GSE Packet into the selected frame (depending on the scheduler policy) as first GSE packet or 
after any other GSE Packet already present in the frame. The same operation is repeated for all the PDU 
fragments, except the last. 

Finally, the GSE Encapsulator takes the remaining X3 (see figure 3) PDU data and: 

• forms a GSE Packet with S bit value set to "0" and the E bit value set to "1"; 

• sets the GSE Length Field in the GSE Header to the calculated number of bytes including the length of the 
PDU data XJ, of the Frag ID field and the size of the CRC-32. The derived GSE length shall not exceed the 
remaining free space in the current Base Band frame Data Field; 

• sets the Frag ID to the same value as for the previous fragments of this PDU; 

• inserts the remaining X3 (see figure 3) PDU data in the GSE Payload and appends the CRC-32; and 

• then places this GSE Packet into the selected Base Band frame (depending on the scheduler policy) as first 
GSE Packet or after any other GSE Packet already present in the frame. 
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Labels: Addresses and Binding 



The GSE Label Field is optional. Depending on the Label Type Indicator of the GSE Header, the Label field can have a 
length of 6 byte, 3 byte or be omitted. 

This field shall be carried (i.e. Label Type Indicator set to "00" or "01") for IP unicast packets destined to routers using 
shared links (i.e., where the same link connects multiple Receivers). A sender may omit this field (Label Type Indicator 
set to " 10") for an IP unicast packet and/or multicast packets delivered to Receivers that are able to utilize a 
discriminator field (e.g. the IPv4/IPv6 destination address, or a bridged MAC destination address) of the encapsulated 
protocol, which could be interpreted as a Layer 2 address. 

When the GSE Header Label Type Indicator is set to "00", a 6 byte Label (e.g. a Network Point of Attachment NPA 
field) directly follows the Protocol Type Field of the GSE Header. 

When the GSE Header Label Type Indicator is set to "01", a 3 byte Label (e.g. a Network Point of Attachment NPA 
field) directly follows the Protocol Type Field of the GSE Header. Receiver processing of GSE Packets with 3-byte 
labels is optional. 

In the default addressing mode. Labels will correspond to NPA destination addresses that are 6 byte numbers, normally 
expressed in hexadecimal. Labels can be used to identify those Receiver(s) in the network that should process a specific 
GSE Packet. The 3 byte Label can be used as an alternative addressing, for instance in DVB-RCS networks where the 
3 byte label can represent the 1-byte group ID and 2 byte logon ID. 

The value 0x00:00:00:00:00:00, shall not be used as a Label in a GSE Packet. The least significant bit of the first byte 
of the Label is set to "1" for multicast frames, and the remaining bytes specify the link layer multicast address. The 
specific value OxFF:FF:FF:FF:FF:FF is the link broadcast address, indicating that the reassembled (if fragmented) PDU 
is to be delivered to all Receivers. 

IPv4 packets carrying an IPv4 subnetwork broadcast address need to be delivered to all systems with the same network 
prefix. When a GSE 6 byte Label is present (Label Type Indicator set to "00") the 6 byte Label shall be set to the NPA 
link broadcast address (OxFF:FF:FF:FF:FF:FF). When the PDU is an IP multicast packet and a GSE 6 byte Label is 
present (Label Type Indicator set to "00"), the IP group destination address of the multicast packet shall be mapped to 
the multicast GSE Label (following the method used to generate a destination MAC address in Ethernet). The method 
for mapping IPv4 multicast addresses is specified in [7]. The method for mapping IPv6 multicast addresses is specified 
in [8]. 

If several consecutive PDUs are sent to the same destination, label re-use can be utilized to save overhead. In this case, 
the Label field of all concatenated GSE Packets except the first one can be omitted and the Label Type Indicator is set 
to "11". The first of the concatenated GSE Packets shall contain a 3 byte Label or a 6 byte Label (Label Type Indicator 
is set to "00" or "01"). A receiver which receives a GSE Packet in label re-use mode assumes that the label of the 
previously received GSE Packet is still valid. Label re-use is allowed in the case of GSE Packets transmitted within the 
same Base Band frame. 

In GSE the simultaneous use of several 6-byte and one 3-byte addresses is supported. For each address a binding 
mechanism needs to be devised. 

A terminal shall use the following bindings: 



• 



All terminals with a unicast MAC address, shall use their MAC hardware address as 6-byte address; this 
binding shall be valid for all terminal types (e.g. S2-receive-only, DVB-RCS, terrestrial return link, etc.) 

• Terminals shall use mechanism for IP to MAC mapping described in [7] and [8] for IPV4 and IPv6 multicast 
addresses when signalled in the forward link (see clause 6). 

A terminal may also support further addressing modes, for instance: 

• Terminals may use the mechanism described in [4] for no-address mode. 

• DVB-RCS terminals may bind their group/logon-ID to the 3-byte address if this mapping is signalled in the 
forward link (see clause 6). 
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Other 3 byte label bindings are possible: 

ATM: binding to VCI/VPI (see clause 6). 

VLAN extension (3 byte MAC address as VLAN ID for simple cases, implicit binding with dedicated 
group marker, e.g. OxFFFF) (see clause 6). 



GSE SI specifications 



For signalling on an MPEG-TS the presence of a GSE stream, an IP/MAC generic_stream_location_descriptor as 
defined in clause 8.4.5.15 of EN 301 192 [3] shall be carried in an IP/MAC Notification Table (also see [3]). 

The selector bytes in the IP/MAC generic_stream_location_descriptor shall be used to convey the following 
generic_stream_binding_inf o . 

Table 4: Syntax for generic_stream_bmdingJnfo 



Syntax 


Number of bits 


Mnemonic 


generic_stream_binding_info () { 






rfc_multicast_binding 


1 


bslbf 


dvb-rcs group logon id binding 


1 


bslbf 


atm_pvc_binding 


1 


bslbf 


vlan extension binding 


1 


bslbf 


Reserved 


12 


bslbf 


} 







rfc_multicast_binding: The service shall set this flag to "1" if it uses the IP to MAC mapping as described in [7] for 
IPv4 multicast addresses and [8] for IPv6 multicast addresses. If this flag is set to "0", the mapping of IP addresses to 
MAC addresses for multicast addresses is done outside the scope of the present document. 

dvb_rcs_group_logon_id_binding: The service shall set this flag to "1" if the interactive terminal has to bind to its 
groupid/logon_id as a 3_byte_label. 

atm_pvc_binding: The service shall set this flag to "1" if VPIA^CI is translated in a 3_byte_label. 

vlan_extension_binding: The service shall set this flag to "1" if vlan_id is translated in a 3_byte_label. 
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Annex A (normative): 
Receiver Processing 



A Receiver tunes to a specific Generic Continuous Stream and sets a receive filter to accept all frames for that specific 
stream. These frames are reassembled to form a stream of GSE Packets. A single Receiver may be able to receive 
multiple Generic Streams. In each case, reassembly shall be performed independently for each Generic Stream and for 
each fragmented PDU. To perform this reassembly, the Receiver may use a buffer to hold the partially assembled PDU. 
Implementations may choose to use other data structures, but shall provide equivalent operations. 

As a minimum, the receiver shall implement one reassembly buffer for each address that it binds to. An advanced 
network supporting QoS mechanisms may use different Frag IDs per address to allow for interleaving PDU fragments 
to the same address. Therefore, in this kind of networks, a receiver may need to be able to handle per Generic Stream a 
larger number of concurrently fragmented PDUs up to a maximum of 256. 

The receiver shall start processing the first GSE Packet which starts directly after the Base Band frame header and then 
continue with all following GSE Packets. The receiver can determine the start of the next GSE Packet by calculating the 
length of the current GSE Packet from the GSE Length field in the GSE Header. 

NOTE: There may be more than one GSE Packet per Base Band frame. 



A.1 Filtering 



The receiver shall filter the GSE Packets for certain labelling modes (e.g. 3-byte or 6-byte labels). If the S bit in the 
GSE Header is set to "1" (one), the receiver shall interpret the label bits. If the GSE Header contains a 6-byte or 3-byte 
label matching any of the filters, the receiver continues with the processing the packet. Otherwise the receiver shall 
discard the GSE Packet and continue processing with the next GSE Packet. If the LT-bits are set to "10" (no label 
present), the receiver shall process the packet regardless of any filters. If the LT field is set to "11" (label re-use mode), 
the receiver shall check if the previous GSE Packet in the frame was destined for the receiver. If so, the receiver 
processes the packet, otherwise the receiver shall discard the GSE Packet. The use of a LT value of " 1 1 " after a 
previous LT value of "10" (no label) is illegal. 

If the S and E bits are both set to "1", the GSE Packet contains a single PDU. The receiver reads the GSE Length field 
and can process the packet (see clause A.3), otherwise the GSE Packet is subject to reassembly processing (see 
clause A.2). 



A.2 Reassembly 



If the S bit is set to "1" and the E bit is set to "0", the GSE Packet contains the first fragment of a PDU with the given 
Frag ID. Prior to entering the reassembly process for this Frag ID, the receiver shall: 

• check whether the ID is already in use, i.e. the receiver has fragments for that Frag ID in a reassembly buffer. 
If the Frag ID is already in use, the receiver shall first discard the already buffered fragments corresponding to 
this Frag ID; 

• enter the reassembly process for the given Frag ID and start reassembly of a new PDU. The required buffer 
space can be derived from the Total Length field. 

When the S bit is set to "0", the GSE Packet contains a continuation or end fragment. If the receiver has a buffer in the 
re-assembly state for the Frag ID corresponding to that in the GSE Header, it continues with processing. Otherwise, the 
GSE Packet shall be discarded. 

If the S bit is set to "0" and the E bit is set to "0", the GSE Packet contains a continuation fragment of a PDU with the 
Frag ID corresponding to that in the GSE Header. It shall add the fragment to the re-assembly buffer. The receiver may 
check the size of the fragment to ensure that the total reassembled length does not exceed the size of Total Length (if it 
does, the receiver shall discard the already buffered fragments corresponding to this Frag ID and abort the reassembly). 
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If the S bit is set to "0" and the E bit is set to " 1 ", the GSE Packet contains the last fragment of a PDU with the Frag ID 
given in the GSE Header. The receiver shall add the fragment to the re-assembly buffer for this Frag ID. The receiver 
shall verify if the number of received bytes, including the length of the unfragmented PDU, of the Protocol Type field, 
of the Label field (if present ), and of any extension header, corresponds to the Total Length field value in the first GSE 
Packet for this PDU. If the length of the re-assembled PDU plus the additional above listed fields does not match the 
Total Length, the receiver shall discard the PDU. Finally the receiver shall check the CRC (last 4 bytes of the current 
GSE Packet) against the CRC of the current PDU buffer. If the CRC does not match, the receiver shall discard the 
current PDU buffer. This error event should be recorded as a PDU CRC error. If the CRC matches, the encapsulated 
PDU has been correctly received and the PDU shall be processed (see clause A. 3). The receiver shall then free this Frag 
ID to allow for re-use of the same Frag ID by following PDUs. 

If a PDU belonging to a given Frag ID cannot be re-assembled within 255 consecutive frames, the receiver shall discard 
the buffer and free the Frag ID. This error event should be recorded as a PDU reassembly time-out error. 



A.3 Protocol Type and Next Header Processing 

After receiving a valid and complete PDU, the receiver starts processing by inspecting the Type field. A set of header 
types are described in [4] and [9], other types may be specified in the Next Header Registry. 

A Type field value less than 256 indicates a Mandatory Extension Header. The receiver shall perform the processing for 
the specified Type field value. Further extension headers may follow this extension header. All unimplemented values 
cause the received data to be discarded, and processing continues with the next GSE packet. This error event should be 
recorded as a PDU extension header error. 

A Type field value between 256 and 1 535 indicates an Optional Extension Header. If implemented, the receiver 
performs the processing for the specified Type field value, otherwise it discards the next header field, and continues 
processing by inspecting the next Type value. Further extension headers may follow this extension header. 

The PDU payload shall then passed to the next protocol layer. A PDU with a Type field value greater than 1 536 which 
is not supported by a receiver may be discarded. This error event should be recorded as a PDU type error. 



A.4 Label re-use 



If the first GSE packet in the Base Band frame has the Label Type Indicator set to "11", the Receiver shall discard the 
GSE packet and process the following GSE packet, until it detects a GSE Packet whose Label Type Indicator is not set 
to "11". 



A.5 Padding 



When receiving a GSE Header, where the Start Indicator and the End Indicator are set to "0", and the Label Type 
Indicator is set to "00", padding is detected and the Receiver shall discard all the following bytes until the end of the 
Base Band frame. 
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Annex B (informative): 
Encapsulator Processing 

B.1 Encapsulator/Scheduler Functions 

Figure B.l shows a block diagram highlighting the key functions related to the scheduling and encapsulation process, 
which take place at the transmitter. This high-level representation is not intended to specify a GSE encapsulation 
implementation, but rather to exemplify the main functional elements and their interrelations. 
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Figure B.1 : Encapsulator/scheduler block diagram 

First, the un- shaded blocks are discussed. The second step will analyze the shaded blocks, which are an aggregation of 
the elementary plain blocks, analyzing how additional interrelations and joint operation can bring significant benefits in 
terms of system efficiency. 

Incoming IP or other network layer packets are processed and routed into different buffers depending on their 
destination and QoS requirements/priority. When an ACM system is considered, the channel quality of the destination 
terminal shall also be taken into account. Following such classification, the scheduler selects packets to be transmitted, 
based on a specific scheduling policy, which in general aims at maximizing capacity while guaranteeing achievement of 
individual QoS targets. 

The PDUs, output from the scheduler, will be fragmented and encapsulated (including the addition of any required 
extension headers) to form GSE Packets (PDU encapsulator/slicer), and further allocated into Base Band frames (GSE 
Packets scheduler). The generated Base Band frames are then sent to the modulator, together with an indication of the 
corresponding transmission parameters (coding rate, modulation format) if ACM is utilized. 

A design that fully exploits the Base Band frame payload minimizing padding overhead is possible when knowledge of 
the frame length is used for ad-hoc fragmentation of the incoming encapsulated PDUs (see figure 1). In this case, there 
is a relation between the function of PDU encapsulation and fragmentation and the GSE Packet allocation into the Base 
Band frame; a feedback from the GSE Packet scheduler to the PDU encapsulator may be required. Therefore the two 
functions may be thought of as being jointly performed by a single and more complex block, named here GSE 
encapsulator. 

When ACM is utilized, each receiver will in general only decode a part of the transmitted data stream, and in particular 
only the frames transmitted with modulation and coding parameters fitting the receiver terminal channel quality. This is 
the reason why it is necessary for the scheduling of GSE Packets into frames to take into account the ACM information 
related to the terminal to which a particular PDU was addressed. 
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A scheduler in the GSE encapsulator, which performs smart placement of GSE Packets in the Base Band frames, allows 
for optimizing system efficiency. The rational is exemplified in figures B.2 and B.3, where a study case is proposed. In 
figure B.2, PDUl, PDU2 and PDU3 form a sequence of PDUs, pre-scheduled by the outer scheduler. The term 
MODCOD indicates the modulation format and coding rate associated to a given PDU. This assumes that the efficiency 
of M0DC0D2 is higher that the one of MODCOD 1, i.e. MODCOD 1 corresponds to a more robust transmission. The 
PDUs are encapsulated and scheduled into Base Band Frames by the GSE encapsulator. 
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Figure B.2: Disjoint encapsulation/scheduling 

When a PDU is fragmented, for example to optimally fill the Base Band Frame Data Field, as in the case for the PDU2 
in the above example, the remaining PDU fragment is encapsulated in an independent GSE Packet, which shall be 
transmitted in one of the following Base Band Frames. However, if no smart scheduling strategy is utilized, the 
generated GSE Packet will be scheduled for a Base Band Frame, together with other pre-scheduled encapsulated PDUs. 
Since the transmission parameters are constant for the same frame, the encapsulator shall "downgrade" to MODCOD 1 
the fragment of the following PDU required to fill the frame. This implies a degradation of the instantaneous channel 
capacity with respect to the achievable one, due to the disjoint scheduling and encapsulation process. Figure B.3 shows 
how a joint operation of scheduling and encapsulation can eliminate link efficiency losses and can achieve a better 
system efficiency. 
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Figure B.3: Joint scheduling/encapsulation 

The issue of distributing scheduling functions between the outer scheduler and the inner GSE Packets scheduler is not 
addressed in the present document. It is dependent both on the selected scheduling routine and on implementation 
issues. However, GSE allows for a fully flexible scheduling of encapsulated PDU and PDU fragments into the Base 
Band Frames, provided that GSE Packets including fragments of the same PDU are transmitted in order. With a joint 
optimized operation of scheduler and encapsulation, the overall system efficiency can be optimized. 
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B.2 Use of the Label Type Indicator 

The Label Type Indicator allows an Encapsulator to notify the receivers about the format of the NPA address that it 
should use for filtering of received GSE Packets. The presence of a Label Type Indicator in each GSE Packet for a 
series of GSE Packets destined for the same NPA address is redundant, and may be optimized by using the LT value of 
"11". An Encapsulator shall use the Label Type value of " 1 1 " only within the scope of one single frame, and never for 
the first GSE packet of a frame. This rule prevents ambiguities in the case of frame loss. 
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Annex (informative): 

GSE Packet Format Examples 

The following figures show example study cases of GSE Packet format. 
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Figure C.1 : GSE Packet carrying a full, unfragmented PDU with a 6 byte NPA Address 
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Figure C.2: GSE Packet carrying a full, unfragmented PDU with a 3 byte NPA Address 
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Figure C.3: A sequence of GSE Packets carrying the start, continuation and end of a PDU 
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Figure C.4: Concatenated GSE Packets: GSE Packet formats and allocation in a Base Band Frame 
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Figure C.5: GSE encapsulation of MPEG signalling packets [9] 
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